• Add setters to CJS compatibility layer in Settings module
• Enables CJS consumers to mutate settings properties
• Fixes TypeError when plugins write to settings
• Allows ep_webrtc and similar plugins to modify settings in tests

Add setter to CJS property descriptors

• Added setter function to property descriptor in CJS compatibility block
• Setter allows writing to settings properties via (settings as any)[key] = v
• Maintains existing getter, enumerable, and configurable properties
• Enables plugins to mutate settings in tests without TypeError

src/node/utils/Settings.ts

Description

This bug fix changes module.exports property descriptors to add a setter, but the PR does not
include any accompanying regression test to ensure CJS consumers can mutate settings. Without an
automated test, the issue can silently reoccur if this change is reverted or refactored.

Code

src/node/utils/Settings.ts[R670-676]

    if (!(key in currentExports)) {
      Object.defineProperty(currentExports, key, {
        get: () => (settings as any)[key],
+        set: (v: any) => { (settings as any)[key] = v; },
        enumerable: true,
        configurable: true,
      });

Evidence

PR Compliance ID 1 requires a regression test for bug fixes. The only change shown is the setter
addition in Settings.ts, and no test additions/updates are included alongside this fix.

src/node/utils/Settings.ts[670-676]
Best Practice: Repository guidelines

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A bug fix was made to allow CJS consumers to mutate settings (by adding a `set` handler in the `module.exports` compatibility block), but no regression test was added.

## Issue Context
Without a test, a future refactor (or revert) could reintroduce `TypeError: Cannot set property which has only a getter` for CJS consumers.

## Fix Focus Areas
- src/node/utils/Settings.ts[670-676]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The CJS compatibility layer only defines getters/setters for Object.keys(settings) at module
initialization, so keys added later by storeSettings() (including plugin-specific ep_* keys) are
not accessible or writable via require('.../Settings').<key> even though they exist on the
underlying settings object.

Code

src/node/utils/Settings.ts[R670-676]

    if (!(key in currentExports)) {
      Object.defineProperty(currentExports, key, {
        get: () => (settings as any)[key],
+        set: (v: any) => { (settings as any)[key] = v; },
        enumerable: true,
        configurable: true,
      });

Evidence

The CJS shim defines properties only for the initial default keys (before configuration is loaded).
Later, reloadSettings() calls storeSettings(), which explicitly supports plugin-specific keys
(ep_*) and assigns them onto the settings object—after the shim has already run—so those new
keys will not be proxied onto module.exports.

src/node/utils/Settings.ts[664-679]
src/node/utils/Settings.ts[731-753]
src/node/utils/Settings.ts[959-963]
src/node/utils/Settings.ts[1120-1121]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The CommonJS compatibility shim only defines properties for the keys present in `settings` at module initialization. Keys added later (for example `ep_*` plugin settings populated by `storeSettings()` during `reloadSettings()`) are not exposed on `module.exports`, so CJS consumers cannot read/write them via `require(.../Settings).ep_plugin`.

### Issue Context
- The shim runs immediately after `export default settings`.
- `reloadSettings()` later calls `storeSettings()` which can add new keys (notably `ep_*`).

### Fix Focus Areas
- src/node/utils/Settings.ts[664-679]
- src/node/utils/Settings.ts[731-759]
- src/node/utils/Settings.ts[959-964]

### Suggested fix
Add a small helper (e.g., `ensureCjsExportKey(key: string)`) that defines the same getter/setter on `module.exports` for a given key if it is missing. Call it:
1) Inside the existing initialization loop (current behavior), and
2) Inside `storeSettings()` after assigning `settings[i]` (especially when `i.startsWith('ep_')` or when `settings[i]` transitions from `undefined` to defined).

This keeps the CJS surface in sync with dynamically-added settings keys.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools